SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Reactive programming</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Reactive programming</span></span>

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}@media print{body.ns-0 .mw-parser-output .ambox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style>

<p>In <a href="Computing" title="Computing">computing</a>, <b>reactive programming</b> is a <a href="Declarative_programming" title="Declarative programming">declarative</a> <a href="Programming_paradigm" title="Programming paradigm">programming paradigm</a> concerned with <a href="Stream_(computing)" title="Stream (computing)">data streams</a> and the propagation of change. With this paradigm, it is possible to express static (e.g., arrays) or dynamic (e.g., event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow.

</p><p>For example, in an <a href="Imperative_programming" title="Imperative programming"><i>imperative</i> programming</a> setting, <code>a := b + c</code> would mean that <code>a</code> is being assigned the result of <code>b + c</code> at the instant the expression is evaluated, and later, the values of <code>b</code> and <code>c</code> can be changed with no effect on the value of <code>a</code>. On the other hand, in <i>reactive</i> programming, the value of <code>a</code> is automatically updated whenever the values of <code>b</code> or <code>c</code> change, without the program having to explicitly re-state the statement <code>a := b + c</code> to re-assign the value of <code>a</code>.

</p>

<span class="nx">console</span><span class="p">.</span><span class="nx">log</span><span class="p">(</span><span class="nx">a</span><span class="p">)</span><span class="w"> </span><span class="c1">// 3 (not 12 because "=" is not a reactive assignment operator)</span>

<span class="c1">// now imagine you have a special operator "$=" that changes the value of a variable (executes code on the right side of the operator and assigns result to left side variable) not only when explicitly initialized, but also when referenced variables (on the right side of the operator) are changed</span>

</pre></div>

<p>Another example is a <a href="Hardware_description_language" title="Hardware description language">hardware description language</a> such as <a href="Verilog" title="Verilog">Verilog</a>, where reactive programming enables changes to be modeled as they propagate through circuits.

</p><p>Reactive programming has been proposed as a way to simplify the creation of interactive user interfaces and near-real-time system animation.

</p><p>For example, in a <a href="Model%E2%80%93view%E2%80%93controller" title="Model–view–controller">model–view–controller</a> (MVC) architecture, reactive programming can facilitate changes in an underlying <i>model</i> being reflected automatically in an associated <i>view</i>.<sup id="cite_ref-refTrellis_1-0" class="reference"><a href="#cite_note-refTrellis-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Approaches_to_creating_reactive_programming_languages">Approaches to creating reactive programming languages</h2></div>

<p>Several popular approaches are employed in the creation of reactive programming languages. One approach is the specification of <i>dedicated</i> languages that are specific to various <i>domain constraints</i>. Such constraints usually are characterized by real-time, embedded computing or hardware description. Another approach involves the specification of <i>general-purpose</i> languages that include support for reactivity. Other approaches are articulated in the definition, and use of programming <i>libraries</i>, or <i>embedded <a href="Domain-specific_language" title="Domain-specific language">domain-specific languages</a></i>, that enable reactivity alongside or on top of the programming language. Specification and use of these different approaches results in language <i>capability trade-offs</i>. In general, the more restricted a language is, the more its associated compilers and analysis tools are able to inform developers (e.g., in performing analysis for whether programs are able to execute in actual real-time). Functional trade-offs in specificity may result in deterioration of the general applicability of a language.

</p>

<div class="mw-heading mw-heading2"><h2 id="Programming_models_and_semantics">Programming models and semantics</h2></div>

<p>A variety of models and semantics govern reactive programming. We can loosely split them along the following dimensions:

</p>

<ul><li>Synchrony: synchronous versus asynchronous model of time</li>

<li>Determinism: deterministic versus non-deterministic evaluation process and results</li>

<li>Update process: <a href="Callback_(computer_programming)" title="Callback (computer programming)">callback</a> versus dataflow versus actor</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Implementation_techniques_and_challenges">Implementation techniques and challenges</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Essence_of_implementations">Essence of implementations</h3></div>

<p>Reactive programming language runtimes are represented by a graph that identifies the dependencies among the involved reactive values. In such a graph, <i>nodes</i> represent the act of computing, and <i>edges</i> model dependency relationships. Such a runtime employs said graph, to help it keep track of the various computations, which must be executed anew, once an involved input changes value.

</p>

<div class="mw-heading mw-heading4"><h4 id="Change_propagation_algorithms">Change propagation algorithms</h4></div>

<p>The most common approaches to data propagation are:

</p>

<ul><li><b>Pull</b>: The value consumer is in fact <i>proactive</i>, in that it regularly queries the observed source for values and reacts whenever a relevant value is available. This practice of regularly checking for events or value changes is commonly referred to as <i>polling</i>.</li>

<li><b>Push</b>: The value consumer receives a value from the source whenever the value becomes available. These values are self-contained, e.g. they contain all the necessary information, and no further information needs to be queried by the consumer.</li>

<li><b>Push-pull</b>: The value consumer receives a <i>change notification</i>, which is a short description of the change, e.g. "some value changed" – this is the <i>push</i> part. However, the notification does not contain all the necessary information (which means it does not contain the actual values), so the consumer needs to query the source for more information (the specific value) after it receives the notification – this is the <i>pull</i> part. This method is commonly used when there is a large volume of data that the consumers might be potentially interested in. So in order to reduce throughput and latency, only light-weight notifications are sent; and then those consumers which require more information will request that specific information. This approach also has the drawback that the source might be overwhelmed by many requests for additional information after a notification is sent.</li></ul>

<p>At the implementation level, <i>event reaction</i> consists of the propagation across a graph's information, which characterizes the existence of change. Consequently, computations that are affected by such change then become outdated and must be flagged for re-execution. Such computations are then usually characterized by the <a href="Transitive_closure" title="Transitive closure">transitive closure</a> of the change (i.e. the full set of transitive dependencies a source affects) in its associated source. <i>Change propagation</i> may then lead to an update in the value of the graph's <i>sinks</i>.

</p><p>Graph propagated information can consist of a node's complete state, i.e., the computation result of the involved node. In such cases, the node's previous output is then ignored. Another method involves <i>delta propagation</i> i.e. <i>incremental change propagation</i>. In this case, information is proliferated along a graph's <i>edges,</i> which consist only of <i>delta</i>s describing how the previous node was changed. This approach is especially important when <i>nodes</i> hold large amounts of <i>state data</i>, which would otherwise be expensive to recompute from scratch.

</p><p><i>Delta propagation</i> is essentially an optimization that has been extensively studied via the discipline of <a href="Incremental_computing" title="Incremental computing">incremental computing</a>, whose approach requires runtime satisfaction involving the <a href="Database#External.2C_conceptual.2C_and_internal_views" title="Database">view-update problem</a>. This problem is infamously characterized by the use of <a href="Database" title="Database">database</a> entities, which are responsible for the maintenance of changing data views.

</p><p>Another common optimization is employment of <i>unary change accumulation</i> and <i>batch propagation</i>. Such a solution can be faster because it reduces communication among involved nodes. Optimization strategies can then be employed that reason about the nature of the changes contained within, and make alterations accordingly (e.g. two changes in the batch can cancel each other, and thus, simply be ignored). Yet another available approach, is described as <i>invalidity notification propagation</i>. This approach causes nodes with invalid input to pull updates, thus resulting in the update of their own outputs.

</p><p>There are two principal ways employed in the building of a <i><a href="Dependency_graph" title="Dependency graph">dependency graph</a></i>:

</p>

<ol><li>The graph of dependencies are maintained implicitly within an <i><a href="Event_loop" title="Event loop">event loop</a></i>. Registration of explicit callbacks then results in the creation of implicit dependencies. Therefore, <i>control inversion</i>, which is induced via callback, is thus left in place. However, making callbacks functional (i.e. returning state value instead of unit value) necessitates that such callbacks become compositional.</li>

<li>A graph of dependencies is program-specific and generated by a programmer. This facilitates an addressing of the callback's <i>control inversion</i> in two ways: either a graph is specified <i>explicitly</i> (typically using a <i><a href="Domain-specific_language" title="Domain-specific language">domain-specific language</a></i> (DSL), which may be embedded), or a graph is <i>implicitly</i> defined with expression and generation using an effective, archetypal <i>language</i>.</li></ol>

<div class="mw-heading mw-heading3"><h3 id="Implementation_challenges_in_reactive_programming">Implementation challenges in reactive programming</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Glitches">Glitches</h4></div>

<p>When propagating changes, it is possible to pick propagation orders such that the value of an expression is not a natural consequence of the source program. We can illustrate this easily with an example. Suppose <code>seconds</code> is a reactive value that changes every second to represent the current time (in seconds). Consider this expression:

</p>

<pre>t = seconds + 1

g = (t > seconds)

</pre>

<p>Because <code>t</code> should always be greater than <code>seconds</code>, this expression should always evaluate to a true value. Unfortunately, this can depend on the order of evaluation. When <code>seconds</code> changes, two expressions have to update: <code>seconds + 1</code> and the conditional. If the first evaluates before the second, then this invariant will hold. If, however, the conditional updates first, using the old value of <code>t</code> and the new value of <code>seconds</code>, then the expression will evaluate to a false value. This is called a <i>glitch</i>.

</p><p>Some reactive languages are glitch-free and prove this property. This is usually achieved by <a href="Topological_sorting" title="Topological sorting">topologically sorting</a> expressions and updating values in topological order. This can, however, have performance implications, such as delaying the delivery of values (due to the order of propagation). In some cases, therefore, reactive languages permit glitches, and developers must be aware of the possibility that values may temporarily fail to correspond to the program source, and that some expressions may evaluate multiple times (for instance, <code>t > seconds</code> may evaluate twice: once when the new value of <code>seconds</code> arrives, and once more when <code>t</code> updates).

</p>

<div class="mw-heading mw-heading4"><h4 id="Cyclic_dependencies">Cyclic dependencies</h4></div>

<p>Topological sorting of dependencies depends on the dependency graph being a <a href="Directed_acyclic_graph" title="Directed acyclic graph">directed acyclic graph</a> (DAG). In practice, a program may define a dependency graph that has cycles. Usually, reactive programming languages expect such cycles to be "broken" by placing some element along a "back edge" to permit reactive updating to terminate. Typically, languages provide an operator like <code>delay</code> that is used by the update mechanism for this purpose, since a <code>delay</code> implies that what follows must be evaluated in the "next time step" (allowing the current evaluation to terminate).

</p>

<div class="mw-heading mw-heading4"><h4 id="Interaction_with_mutable_state">Interaction with mutable state</h4></div>

<p>Reactive languages typically assume that their expressions are <a href="Pure_function" title="Pure function">purely functional</a>. This allows an update mechanism to choose different orders in which to perform updates, and leave the specific order unspecified (thereby enabling optimizations). When a reactive language is embedded in a programming language with state, however, it may be possible for programmers to perform mutable operations. How to make this interaction smooth remains an open problem.

</p><p>In some cases, it is possible to have principled partial solutions. Two such solutions include:

</p>

<ul><li>A language might offer a notion of a "mutable cell". A mutable cell is one that the reactive update system is aware of, so that changes made to the cell propagate to the rest of the reactive program. This enables the non-reactive part of the program to perform a traditional mutation while enabling reactive code to be aware of and respond to this update, thus maintaining the consistency of the relationship between values in the program. An example of a reactive language that provides such a cell is FrTime.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup></li>

<li>Properly encapsulated object-oriented libraries offer an encapsulated notion of state. In principle, it is therefore possible for such a library to interact smoothly with the reactive portion of a language. For instance, callbacks can be installed in the getters of the object-oriented library to notify the reactive update engine about state changes, and changes in the reactive component can be pushed to the object-oriented library through getters. FrTime employs such a strategy.<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup></li></ul>

<div class="mw-heading mw-heading4"><h4 id="Dynamic_updating_of_the_graph_of_dependencies">Dynamic updating of the graph of dependencies</h4></div>

<p>In some reactive languages, the graph of dependencies is <i>static</i>, i.e., the graph is fixed throughout the program's execution. In other languages, the graph can be <i>dynamic</i>, i.e., it can change as the program executes. For a simple example, consider this illustrative example (where <code>seconds</code> is a reactive value):

</p>

<pre>t =

if ((seconds mod 2) == 0):

seconds + 1

else:

seconds - 1

end

t + 1

</pre>

<p>Every second, the value of this expression changes to a different reactive expression, which <code>t + 1</code> then depends on. Therefore, the graph of dependencies updates every second.

</p><p>Permitting dynamic updating of dependencies provides significant expressive power (for instance, dynamic dependencies routinely occur in <a href="Graphical_user_interface" title="Graphical user interface">graphical user interface</a> (GUI) programs). However, the reactive update engine must decide whether to reconstruct expressions each time, or to keep an expression's node constructed but inactive; in the latter case, ensure that they do not participate in the computation when they are not supposed to be active.

</p>

<div class="mw-heading mw-heading2"><h2 id="Concepts">Concepts</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Degrees_of_explicitness">Degrees of explicitness</h3></div>

<p>Reactive programming languages can range from very explicit ones where data flows are set up by using arrows, to implicit where the data flows are derived from language constructs that look similar to those of imperative or functional programming. For example, in an implicitly lifted <a href="Functional_reactive_programming" title="Functional reactive programming">functional reactive programming</a> (FRP), a function call might implicitly cause a node in a data flow graph to be constructed. Reactive programming libraries for dynamic languages (such as the Lisp "Cells" and Python "Trellis" libraries) can construct a dependency graph from runtime analysis of the values read during a function's execution, allowing data flow specifications to be both implicit and dynamic.

</p><p>Sometimes the term <i>reactive programming</i> refers to the architectural level of software engineering, where individual nodes in the data flow graph are ordinary programs that communicate with each other.

</p>

<div class="mw-heading mw-heading3"><h3 id="Static_or_dynamic">Static or dynamic</h3></div>

<p>Reactive programming can be purely static where the data flows are set up statically, or be dynamic where the data flows can change during the execution of a program.

</p><p>The use of data switches in the data flow graph could to some extent make a static data flow graph appear as dynamic, and blur the distinction slightly. True dynamic reactive programming however could use imperative programming to reconstruct the data flow graph.

</p>

<div class="mw-heading mw-heading3"><h3 id="Higher-order_reactive_programming">Higher-order reactive programming</h3></div>

<p>Reactive programming could be said to be of <b>higher order</b> if it supports the idea that data flows could be used to construct other data flows. That is, the resulting value out of a data flow is another data flow graph that is executed using the same evaluation model as the first.

</p>

<div class="mw-heading mw-heading3"><h3 id="Data_flow_differentiation">Data flow differentiation</h3></div>

<p>Ideally all data changes are propagated instantly, but this cannot be assured in practice. Instead, it might be necessary to give different parts of the data flow graph different evaluation priorities. This can be called <b>differentiated reactive programming</b>.

</p><p>For example, in a word processor, the marking of spelling errors need not be totally in sync with the inserting of characters. Here differentiated reactive programming could potentially be used to give the spell checker lower priority, allowing it to be delayed while keeping other data-flows instantaneous.

</p><p>However, such differentiation introduces additional design complexity. For example, deciding how to define the different data flow areas, and how to handle event passing between different data flow areas.

</p>

<div class="mw-heading mw-heading3"><h3 id="Evaluation_models_of_reactive_programming">Evaluation models of reactive programming</h3></div>

<p>Evaluation of reactive programs is not necessarily based on how stack-based programming languages are evaluated. Instead, when some data is changed, the change is propagated to all data that is derived partially or completely from the data that was changed. This change propagation could be achieved in a number of ways, where perhaps the most natural way is an invalidate/lazy-revalidate scheme.

</p><p>It could be problematic simply to naively propagate a change using a stack, because of potential exponential update complexity if the data structure has a certain shape. One such shape can be described as "repeated diamonds shape", and has the following structure:

A<sub>n</sub>→B<sub>n</sub>→A<sub>n+1</sub>, A<sub>n</sub>→C<sub>n</sub>→A<sub>n+1</sub>, where n=1,2... This problem could be overcome by propagating invalidation only when some data is not already invalidated, and later re-validate the data when needed using <a href="Lazy_evaluation" title="Lazy evaluation">lazy evaluation</a>.

</p><p>One inherent problem for reactive programming is that most computations that would be evaluated and forgotten in a normal programming language, needs to be represented in the memory as data-structures. This could potentially make reactive programming highly memory consuming. However, research on what is called <i>lowering</i> could potentially overcome this problem.<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p><p>On the other side, reactive programming is a form of what could be described as "explicit parallelism", and could therefore be beneficial for utilizing the power of parallel hardware.

</p>

<div class="mw-heading mw-heading4"><h4 id="Similarities_with_observer_pattern">Similarities with observer pattern</h4></div>

<p>Reactive programming has principal similarities with the <a href="Observer_pattern" title="Observer pattern">observer pattern</a> commonly used in <a href="Object-oriented_programming" title="Object-oriented programming">object-oriented programming</a>. However, integrating the data flow concepts into the programming language would make it easier to express them and could therefore increase the granularity of the data flow graph. For example, the observer pattern commonly describes data-flows between whole objects/classes, whereas object-oriented reactive programming could target the members of objects/classes.

</p>

<div class="mw-heading mw-heading2"><h2 id="Approaches">Approaches</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Imperative">Imperative</h3></div>

<p>It is possible to fuse reactive programming with ordinary <a href="Imperative_programming" title="Imperative programming">imperative programming</a>. In such a paradigm, imperative programs operate upon reactive data structures.<sup id="cite_ref-refDC_5-0" class="reference"><a href="#cite_note-refDC-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> Such a set-up is analogous to <a href="Constraint_programming" title="Constraint programming">imperative constraint programming</a>; however, while imperative constraint programming manages bidirectional data-flow constraints, imperative reactive programming manages one-way data-flow constraints. One reference implementation is the proposed <a rel="nofollow" class="external text" href="https://github.com/webqit/quantum-js">Quantum runtime extension to JavaScript</a> .

</p>

<div class="mw-heading mw-heading3"><h3 id="Object-oriented">Object-oriented</h3></div>

<p>Object-oriented reactive programming (OORP) is a combination of object-oriented programming and reactive programming. Perhaps the most natural way to make such a combination is as follows: instead of methods and fields, objects have <i>reactions</i> that automatically re-evaluate when the other reactions they depend on have been modified.

</p><p>If an OORP language maintains its imperative methods, it would also fall under the category of imperative reactive programming.

</p>

<div class="mw-heading mw-heading3"><h3 id="Functional">Functional</h3></div>

<p><a href="Functional_reactive_programming" title="Functional reactive programming">Functional reactive programming</a> (FRP) is a programming paradigm for reactive programming on <a href="Functional_programming" title="Functional programming">functional programming</a>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Actor_based">Actor based</h3></div>

<p>Actors have been proposed to design reactive systems, often in combination with <a href="Functional_Reactive_Programming" class="mw-redirect" title="Functional Reactive Programming">Functional reactive programming</a> (FRP) and <a href="Reactive_Streams" title="Reactive Streams">Reactive Streams</a> to develop distributed reactive systems.<sup id="cite_ref-stella_6-0" class="reference"><a href="#cite_note-stella-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-stella2_7-0" class="reference"><a href="#cite_note-stella2-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-akka_9-0" class="reference"><a href="#cite_note-akka-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Rule_based">Rule based</h3></div>

<p>A relatively new category of programming languages uses constraints (rules) as main programming concept. It consists of reactions to events, which keep all constraints satisfied. Not only does this facilitate event-based reactions, but it makes reactive programs instrumental to the correctness of software. An example of a rule based reactive programming language is Ampersand, which is founded in <a href="Relation_algebra" title="Relation algebra">relation algebra</a>.<sup id="cite_ref-refSJ_10-0" class="reference"><a href="#cite_note-refSJ-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Implementations">Implementations</h2></div>

<ul><li><a href="ReactiveX" title="ReactiveX">ReactiveX</a>, an API for implementing reactive programming with streams, observables and operators with multiple language implementations including RxJs, RxJava, Rx.NET, RxPy and RxSwift.</li>

<li><a href="Elm_(programming_language)" title="Elm (programming language)">Elm</a>, a reactive composition of web user interfaces.</li>

<li><a href="Reactive_Streams" title="Reactive Streams">Reactive Streams</a>, a JVM standard for asynchronous stream processing with non-blocking backpressure</li>

<li><a rel="nofollow" class="external text" href="https://github.com/IgorBuchelnikov/ObservableComputations">ObservableComputations</a>, a cross-platform .NET implementation.</li>

<li><a href="Svelte" title="Svelte">Svelte</a>, brings reactivity in the form of a variant <a href="JavaScript_syntax" title="JavaScript syntax">JavaScript syntax</a> that looks like <a href="JavaScript" title="JavaScript">JavaScript</a> but is naturally reactive where JavaScript normally isn't.</li>

<li><a rel="nofollow" class="external text" href="https://solidjs.com/">Solid.js</a> brings reactivity to <a href="JavaScript" title="JavaScript">JavaScript</a> without changing <a href="JavaScript_syntax" title="JavaScript syntax">JavaScript syntax</a> semantics, along with reactive <a href="JSX_(JavaScript)" title="JSX (JavaScript)">JSX</a> templating.</li>

<li><a rel="nofollow" class="external text" href="https://github.com/webqit/quantum-js">Quantum JS</a>, a runtime extension to JavaScript that brings imperative reactive programming to the language, creating a whole new category in the reactivity spectrum.</li>

<li><a rel="nofollow" class="external text" href="https://github.com/reactivehtml/rimmel">Rimmel.js</a>, a modern functional-reactive JavaScript UI library designed with RxJS streams in mind.</li></ul>

<ul><li><a href="Observable_(Computing)" class="mw-redirect" title="Observable (Computing)">Observable (Computing)</a>, observable in reactive programming.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFTrellis" class="citation cs2">Trellis, <a rel="nofollow" class="external text" href="http://peak.telecommunity.com/DevCenter/Trellis#model-view-controller-and-the-observer-pattern"><i>Model-view-controller and the observer pattern</i></a>, Tele community, <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160303170619/http://peak.telecommunity.com/DevCenter/Trellis#model-view-controller-and-the-observer-pattern">archived</a> from the original on 2016-03-03<span class="reference-accessdate">, retrieved <span class="nowrap">2009-07-27</span></span></cite>.</span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><b><a href="#cite_ref-2">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/">"Embedding Dynamic Dataflow in a Call-by-Value Language"</a>. <i>cs.brown.edu</i>. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20161018073910/http://cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/">Archived</a> from the original on 2016-10-18<span class="reference-accessdate">. Retrieved <span class="nowrap">2016-10-09</span></span>.</cite></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-3">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://cs.brown.edu/~sk/Publications/Papers/Published/ick-adapt-oo-fwk-frp/">"Crossing State Lines: Adapting Object-Oriented Frameworks to Functional Reactive Languages"</a>. <i>cs.brown.edu</i>. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20161009141647/https://cs.brown.edu/~sk/Publications/Papers/Published/ick-adapt-oo-fwk-frp/">Archived</a> from the original on 2016-10-09<span class="reference-accessdate">. Retrieved <span class="nowrap">2016-10-09</span></span>.</cite></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><b><a href="#cite_ref-4">^</a></b></span> <span class="reference-text"><cite id="CITEREFBurchettCooperKrishnamurthi" class="citation cs2">Burchett, Kimberley; Cooper, Gregory H; Krishnamurthi, Shriram, "Lowering: a static optimization technique for transparent functional reactivity", <a rel="nofollow" class="external text" href="https://cs.brown.edu/~sk/Publications/Papers/Published/bck-lowering-opt-trans-frp/paper.pdf"><i>Proceedings of the 2007 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation</i></a> <span class="cs1-format">(PDF)</span>, pp. <span class="nowrap">71–</span>80, <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160416100136/https://cs.brown.edu/~sk/Publications/Papers/Published/bck-lowering-opt-trans-frp/paper.pdf">archived</a> <span class="cs1-format">(PDF)</span> from the original on 2016-04-16<span class="reference-accessdate">, retrieved <span class="nowrap">2014-09-08</span></span></cite>.</span>

</li>

<li id="cite_note-refDC-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-refDC_5-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFDemetrescuFinocchiRibichini2011" class="citation cs2">Demetrescu, Camil; Finocchi, Irene; Ribichini, Andrea (22 October 2011), "Reactive Imperative Programming with Dataflow Constraints", <a rel="nofollow" class="external text" href="http://dl.acm.org/citation.cfm?id=2048100"><i>Proceedings of the 2011 ACM international conference on Object-oriented programming systems languages and applications</i></a>, Oopsla '11, pp. <span class="nowrap">407–</span>26, <a href="ArXiv_(identifier)" class="mw-redirect" title="ArXiv (identifier)">arXiv</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://arxiv.org/abs/1104.2293">1104.2293</a></span>, <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F2048066.2048100">10.1145/2048066.2048100</a>, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9781450309400</bdi>, <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:7285961">7285961</a></cite>.</span>

</li>

<li id="cite_note-stella-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-stella_6-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFVan_den_VonderRenauxOeyenDe_Koster2020" class="citation cs2">Van den Vonder, Sam; Renaux, Thierry; Oeyen, Bjarno; De Koster, Joeri; De Meuter, Wolfgang (2020), "Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model", <a rel="nofollow" class="external text" href="https://drops.dagstuhl.de/opus/volltexte/2020/13176/"><i>Leibniz International Proceedings in Informatics (LIPIcs)</i></a>, vol. 166, pp. 19:1–19:29, <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://doi.org/10.4230%2FLIPIcs.ECOOP.2020.19">10.4230/LIPIcs.ECOOP.2020.19</a></span>, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9783959771542</bdi>, <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:260445152">260445152</a>, <a rel="nofollow" class="external text" href="https://web.archive.org/web/20211020030213/https://drops.dagstuhl.de/opus/volltexte/2020/13176/">archived</a> from the original on 2021-10-20<span class="reference-accessdate">, retrieved <span class="nowrap">2021-06-24</span></span></cite>.</span>

</li>

<li id="cite_note-stella2-7"><span class="mw-cite-backlink"><b><a href="#cite_ref-stella2_7-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFVan_den_VonderRenauxDe_Meuter2022" class="citation cs2">Van den Vonder, Sam; Renaux, Thierry; De Meuter, Wolfgang (2022), "Topology-Level Reactivity in Distributed Reactive Programs: Reactive Acquaintance Management using Flocks", <a rel="nofollow" class="external text" href="https://programming-journal.org/2022/6/14/"><i>The Art, Science, and Engineering of Programming</i></a>, vol. 6, pp. 14:1–14:36, <a href="ArXiv_(identifier)" class="mw-redirect" title="ArXiv (identifier)">arXiv</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://arxiv.org/abs/2202.09228">2202.09228</a></span>, <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://doi.org/10.22152%2Fprogramming-journal.org%2F2022%2F6%2F14">10.22152/programming-journal.org/2022/6/14</a></span>, <a rel="nofollow" class="external text" href="https://web.archive.org/web/20230315162725/https://programming-journal.org/2022/6/14/">archived</a> from the original on 2023-03-15<span class="reference-accessdate">, retrieved <span class="nowrap">2023-03-16</span></span></cite></span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><b><a href="#cite_ref-8">^</a></b></span> <span class="reference-text"><cite id="CITEREFShibanaiWatanabe2018" class="citation cs2">Shibanai, Kazuhiro; Watanabe, Takuo (2018), "Distributed Functional Reactive Programming on Actor-Based Runtime", <span class="id-lock-subscription" title="Paid subscription required"><a rel="nofollow" class="external text" href="https://dl.acm.org/doi/10.1145/3281366.3281370"><i>Proceedings of the 8th ACM SIGPLAN International Workshop on Programming Based on Actors, Agents, and Decentralized Control</i></a></span>, Agere 2018, pp. <span class="nowrap">13–</span>22, <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F3281366.3281370">10.1145/3281366.3281370</a>, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9781450360661</bdi>, <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:53113447">53113447</a>, <a rel="nofollow" class="external text" href="https://web.archive.org/web/20210624211319/https://dl.acm.org/doi/10.1145/3281366.3281370">archived</a> from the original on 2021-06-24<span class="reference-accessdate">, retrieved <span class="nowrap">2021-06-24</span></span></cite></span>

</li>

<li id="cite_note-akka-9"><span class="mw-cite-backlink"><b><a href="#cite_ref-akka_9-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFRoestenburgBakkerWilliams2016" class="citation book cs1">Roestenburg, Raymond; Bakker, Rob; Williams, Rob (2016). "13: Streaming". <i>Akka in Action</i>. Greenwich, Connecticut, USA: Manning Publications Co. p. 281. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1-61729-101-2</bdi>.</cite></span>

</li>

<li id="cite_note-refSJ-10"><span class="mw-cite-backlink"><b><a href="#cite_ref-refSJ_10-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFJoosten2018" class="citation cs2">Joosten, Stef (2018), "Relation Algebra as programming language using the Ampersand compiler", <i>Journal of Logical and Algebraic Methods in Programming</i>, vol. 100, pp. <span class="nowrap">113–</span>29, <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://doi.org/10.1016%2Fj.jlamp.2018.04.002">10.1016/j.jlamp.2018.04.002</a></span>, <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:52932824">52932824</a></cite>.</span>

</li>

</ol></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://dl.acm.org/citation.cfm?id=2501666">A survey on reactive programming</a> A 2013 paper by E. Bainomugisha, A. Lombide Carreton, T. Van Cutsem, S. Mostinckx, and W. De Meuter that surveys and provides a taxonomy of existing reactive programming approaches.</li>

<li><a rel="nofollow" class="external text" href="http://www-sop.inria.fr/mimosa/rp/generalPresentation/index.html">MIMOSA Project of INRIA - ENSMP</a>, a general site about reactive programming.</li></ul>

<p><br>

</p>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hlist dl,.mw-parser-output .hlist ol,.mw-parser-output .hlist ul{margin:0;padding:0}.mw-parser-output .hlist dd,.mw-parser-output .hlist dt,.mw-parser-output .hlist li{margin:0;display:inline}.mw-parser-output .hlist.inline,.mw-parser-output .hlist.inline dl,.mw-parser-output .hlist.inline ol,.mw-parser-output .hlist.inline ul,.mw-parser-output .hlist dl dl,.mw-parser-output .hlist dl ol,.mw-parser-output .hlist dl ul,.mw-parser-output .hlist ol dl,.mw-parser-output .hlist ol ol,.mw-parser-output .hlist ol ul,.mw-parser-output .hlist ul dl,.mw-parser-output .hlist ul ol,.mw-parser-output .hlist ul ul{display:inline}.mw-parser-output .hlist .mw-empty-li{display:none}.mw-parser-output .hlist dt::after{content:": "}.mw-parser-output .hlist dd::after,.mw-parser-output .hlist li::after{content:" · ";font-weight:bold}.mw-parser-output .hlist dd:last-child::after,.mw-parser-output .hlist dt:last-child::after,.mw-parser-output .hlist li:last-child::after{content:none}.mw-parser-output .hlist dd dd:first-child::before,.mw-parser-output .hlist dd dt:first-child::before,.mw-parser-output .hlist dd li:first-child::before,.mw-parser-output .hlist dt dd:first-child::before,.mw-parser-output .hlist dt dt:first-child::before,.mw-parser-output .hlist dt li:first-child::before,.mw-parser-output .hlist li dd:first-child::before,.mw-parser-output .hlist li dt:first-child::before,.mw-parser-output .hlist li li:first-child::before{content:" (";font-weight:normal}.mw-parser-output .hlist dd dd:last-child::after,.mw-parser-output .hlist dd dt:last-child::after,.mw-parser-output .hlist dd li:last-child::after,.mw-parser-output .hlist dt dd:last-child::after,.mw-parser-output .hlist dt dt:last-child::after,.mw-parser-output .hlist dt li:last-child::after,.mw-parser-output .hlist li dd:last-child::after,.mw-parser-output .hlist li dt:last-child::after,.mw-parser-output .hlist li li:last-child::after{content:")";font-weight:normal}.mw-parser-output .hlist ol{counter-reset:listitem}.mw-parser-output .hlist ol>li{counter-increment:listitem}.mw-parser-output .hlist ol>li::before{content:" "counter(listitem)"\a0 "}.mw-parser-output .hlist dd ol>li:first-child::before,.mw-parser-output .hlist dt ol>li:first-child::before,.mw-parser-output .hlist li ol>li:first-child::before{content:" ("counter(listitem)"\a0 "}

/* end https://en.wikipedia.org/ */

</style><style data-mw-deduplicate="TemplateStyles:r1236075235">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbox{box-sizing:border-box;border:1px solid #a2a9b1;width:100%;clear:both;font-size:88%;text-align:center;padding:1px;margin:1em auto 0}.mw-parser-output .navbox .navbox{margin-top:0}.mw-parser-output .navbox+.navbox,.mw-parser-output .navbox+.navbox-styles+.navbox{margin-top:-1px}.mw-parser-output .navbox-inner,.mw-parser-output .navbox-subgroup{width:100%}.mw-parser-output .navbox-group,.mw-parser-output .navbox-title,.mw-parser-output .navbox-abovebelow{padding:0.25em 1em;line-height:1.5em;text-align:center}.mw-parser-output .navbox-group{white-space:nowrap;text-align:right}.mw-parser-output .navbox,.mw-parser-output .navbox-subgroup{background-color:#fdfdfd}.mw-parser-output .navbox-list{line-height:1.5em;border-color:#fdfdfd}.mw-parser-output .navbox-list-with-group{text-align:left;border-left-width:2px;border-left-style:solid}.mw-parser-output tr+tr>.navbox-abovebelow,.mw-parser-output tr+tr>.navbox-group,.mw-parser-output tr+tr>.navbox-image,.mw-parser-output tr+tr>.navbox-list{border-top:2px solid #fdfdfd}.mw-parser-output .navbox-title{background-color:#ccf}.mw-parser-output .navbox-abovebelow,.mw-parser-output .navbox-group,.mw-parser-output .navbox-subgroup .navbox-title{background-color:#ddf}.mw-parser-output .navbox-subgroup .navbox-group,.mw-parser-output .navbox-subgroup .navbox-abovebelow{background-color:#e6e6ff}.mw-parser-output .navbox-even{background-color:#f7f7f7}.mw-parser-output .navbox-odd{background-color:transparent}.mw-parser-output .navbox .hlist td dl,.mw-parser-output .navbox .hlist td ol,.mw-parser-output .navbox .hlist td ul,.mw-parser-output .navbox td.hlist dl,.mw-parser-output .navbox td.hlist ol,.mw-parser-output .navbox td.hlist ul{padding:0.125em 0}.mw-parser-output .navbox .navbar{display:block;font-size:100%}.mw-parser-output .navbox-title .navbar{float:left;text-align:left;margin-right:0.5em}body.skin--responsive .mw-parser-output .navbox-image img{max-width:none!important}@media print{body.ns-0 .mw-parser-output .navbox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style></div><div role="navigation" class="navbox" aria-labelledby="Programming_paradigms_(Comparison_by_language)368" style="padding:3px"><table class="nowraplinks mw-collapsible autocollapse navbox-inner" style="border-spacing:0;background:transparent;color:inherit"><tbody><tr><th scope="col" class="navbox-title" colspan="2"><style data-mw-deduplicate="TemplateStyles:r1239400231">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbar{display:inline;font-size:88%;font-weight:normal}.mw-parser-output .navbar-collapse{float:left;text-align:left}.mw-parser-output .navbar-boxtext{word-spacing:0}.mw-parser-output .navbar ul{display:inline-block;white-space:nowrap;line-height:inherit}.mw-parser-output .navbar-brackets::before{margin-right:-0.125em;content:"[ "}.mw-parser-output .navbar-brackets::after{margin-left:-0.125em;content:" ]"}.mw-parser-output .navbar li{word-spacing:-0.125em}.mw-parser-output .navbar a>span,.mw-parser-output .navbar a>abbr{text-decoration:inherit}.mw-parser-output .navbar-mini abbr{font-variant:small-caps;border-bottom:none;text-decoration:none;cursor:inherit}.mw-parser-output .navbar-ct-full{font-size:114%;margin:0 7em}.mw-parser-output .navbar-ct-mini{font-size:114%;margin:0 4em}html.skin-theme-clientpref-night .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}@media(prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}}@media print{.mw-parser-output .navbar{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div id="Programming_paradigms_(Comparison_by_language)368" style="font-size:114%;margin:0 4em"><a href="Programming_paradigm" title="Programming paradigm">Programming paradigms</a> (<a href="Comparison_of_multi-paradigm_programming_languages" title="Comparison of multi-paradigm programming languages">Comparison by language</a>)</div></th></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Imperative_programming" title="Imperative programming">Imperative</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em"></div><table class="nowraplinks navbox-subgroup" style="border-spacing:0"><tbody><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Structured_programming" title="Structured programming">Structured</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Jackson_structured_programming" title="Jackson structured programming">Jackson structures</a></li>

<li><a href="Block_(programming)" title="Block (programming)">Block-structured</a></li>

<li><a href="Modular_programming" title="Modular programming">Modular</a></li>

<li><a href="Non-structured_programming" title="Non-structured programming">Non-structured</a></li>

<li><a href="Procedural_programming" title="Procedural programming">Procedural</a></li>

<li><a href="Programming_in_the_large_and_programming_in_the_small" title="Programming in the large and programming in the small">Programming in the large and in the small</a></li>

<li><a href="Design_by_contract" title="Design by contract">Design by contract</a></li>

<li><a href="Invariant-based_programming" title="Invariant-based programming">Invariant-based</a></li>

<li><a href="Nested_function" title="Nested function">Nested function</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Object-oriented_programming" title="Object-oriented programming">Object-oriented</a><br>(<a href="Comparison_of_programming_languages_(object-oriented_programming)" title="Comparison of programming languages (object-oriented programming)">comparison</a>, <a href="List_of_object-oriented_programming_languages" title="List of object-oriented programming languages">list</a>)</th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Class-based_programming" title="Class-based programming">Class-based</a>, <a href="Prototype-based_programming" title="Prototype-based programming">Prototype-based</a>, <a href="Object-based_language" title="Object-based language">Object-based</a></li>

<li><a href="Agent-oriented_programming" title="Agent-oriented programming">Agent</a></li>

<li><a href="Immutable_object" title="Immutable object">Immutable object</a></li>

<li><a href="Persistent_programming_language" title="Persistent programming language">Persistent</a></li>

<li><a href="Uniform_function_call_syntax" title="Uniform function call syntax">Uniform function call syntax</a></li></ul>

</div></td></tr></tbody></table><div></div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Declarative_programming" title="Declarative programming">Declarative</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em"></div><table class="nowraplinks navbox-subgroup" style="border-spacing:0"><tbody><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Functional_programming" title="Functional programming">Functional</a><br>(<a href="Comparison_of_functional_programming_languages" title="Comparison of functional programming languages">comparison</a>)</th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Recursion_(computer_science)" title="Recursion (computer science)">Recursive</a></li>

<li><a href="Anonymous_function" title="Anonymous function">Anonymous function</a> (<a href="Partial_application" title="Partial application">Partial application</a>)</li>

<li><a href="Higher-order_programming" title="Higher-order programming">Higher-order</a></li>

<li><a href="Purely_functional_programming" title="Purely functional programming">Purely functional</a></li>

<li><a href="Total_functional_programming" title="Total functional programming">Total</a></li>

<li><a href="Strict_programming_language" title="Strict programming language">Strict</a></li>

<li><a href="Generalized_algebraic_data_type" title="Generalized algebraic data type">GADTs</a></li>

<li><a href="Dependent_type" title="Dependent type">Dependent types</a></li>

<li><a href="Functional_logic_programming" title="Functional logic programming">Functional logic</a></li>

<li><a href="Tacit_programming" title="Tacit programming">Point-free style</a></li>

<li><a href="Expression-oriented_programming_language" title="Expression-oriented programming language">Expression-oriented</a></li>

<li><a href="Applicative_programming_language" title="Applicative programming language">Applicative</a>, <a href="Concatenative_programming_language" title="Concatenative programming language">Concatenative</a></li>

<li><a href="Function-level_programming" title="Function-level programming">Function-level</a>, <a href="Value-level_programming" title="Value-level programming">Value-level</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Dataflow_programming" title="Dataflow programming">Dataflow</a></th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Flow-based_programming" title="Flow-based programming">Flow-based</a></li>

<li> (<a href="Functional_reactive_programming" title="Functional reactive programming">Functional reactive</a>)</li>

<li><a href="Signal_programming" class="mw-redirect" title="Signal programming">Signals</a></li>

<li><a href="Stream_processing" title="Stream processing">Streams</a></li>

<li><a href="Synchronous_programming_language" title="Synchronous programming language">Synchronous</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Logic_programming" title="Logic programming">Logic</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Abductive_logic_programming" title="Abductive logic programming">Abductive logic</a></li>

<li><a href="Answer_set_programming" title="Answer set programming">Answer set</a></li>

<li><a href="Constraint_programming" title="Constraint programming">Constraint</a> (<a href="Constraint_logic_programming" title="Constraint logic programming">Constraint logic</a>)</li>

<li><a href="Inductive_logic_programming" title="Inductive logic programming">Inductive logic</a></li>

<li><a href="Nondeterministic_programming" title="Nondeterministic programming">Nondeterministic</a></li>

<li><a href="Ontology_language" title="Ontology language">Ontology</a></li>

<li><a href="Probabilistic_logic_programming" title="Probabilistic logic programming">Probabilistic logic</a></li>

<li><a href="Query_language" title="Query language">Query</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Domain-specific_language" title="Domain-specific language">DSL</a></th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Algebraic_modeling_language" title="Algebraic modeling language">Algebraic modeling</a></li>

<li><a href="Array_programming" title="Array programming">Array</a></li>

<li><a href="Automata-based_programming" title="Automata-based programming">Automata-based</a> (<a href="Action_language" title="Action language">Action</a>)</li>

<li><a href="Command_language" title="Command language">Command</a> (<a href="Spacecraft_command_language" title="Spacecraft command language">Spacecraft</a>)</li>

<li><a href="Differentiable_programming" title="Differentiable programming">Differentiable</a></li>

<li><a href="Grammar-oriented_programming" title="Grammar-oriented programming">Grammar-oriented</a></li>

<li><a href="Interface_description_language" title="Interface description language">Interface description</a></li>

<li><a href="Language-oriented_programming" title="Language-oriented programming">Language-oriented</a></li>

<li><a href="List_comprehension" title="List comprehension">List comprehension</a></li>

<li><a href="Modeling_language" title="Modeling language">Modeling</a></li>

<li><a href="Natural-language_programming" class="mw-redirect" title="Natural-language programming">Natural language</a></li>

<li><a href="Non-English-based_programming_languages" title="Non-English-based programming languages">Non-English-based</a></li>

<li><a href="Page_description_language" title="Page description language">Page description</a></li>

<li><a href="Pipeline_(software)" title="Pipeline (software)">Pipes</a> and <a href="Filter_(software)" title="Filter (software)">filters</a></li>

<li><a href="Probabilistic_programming" title="Probabilistic programming">Probabilistic</a></li>

<li><a href="Quantum_programming" title="Quantum programming">Quantum</a></li>

<li><a href="Scientific_programming_language" title="Scientific programming language">Scientific</a></li>

<li><a href="Scripting_language" title="Scripting language">Scripting</a></li>

<li><a href="Set_theoretic_programming" title="Set theoretic programming">Set-theoretic</a></li>

<li><a href="Simulation_language" title="Simulation language">Simulation</a></li>

<li><a href="Stack-oriented_programming" title="Stack-oriented programming">Stack-based</a></li>

<li><a href="System_programming_language" title="System programming language">System</a></li>

<li><a href="Tactile_programming_language" title="Tactile programming language">Tactile</a></li>

<li><a href="Template_processor" title="Template processor">Templating</a></li>

<li><a href="Transformation_language" title="Transformation language">Transformation</a> (<a href="Graph_rewriting" title="Graph rewriting">Graph rewriting</a>, <a href="Production_system_(computer_science)" title="Production system (computer science)">Production</a>, <a href="Pattern_matching" title="Pattern matching">Pattern</a>)</li>

<li><a href="Visual_programming_language" title="Visual programming language">Visual</a></li></ul>

</div></td></tr></tbody></table><div></div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Concurrent_computing" title="Concurrent computing">Concurrent</a>,<br><a href="Distributed_computing" title="Distributed computing">distributed</a>,<br><a href="Parallel_computing" title="Parallel computing">parallel</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Actor_model" title="Actor model">Actor-based</a></li>

<li><a href="Automatic_mutual_exclusion" title="Automatic mutual exclusion">Automatic mutual exclusion</a></li>

<li><a href="Choreographic_programming" title="Choreographic programming">Choreographic programming</a></li>

<li><a href="Concurrent_logic_programming" title="Concurrent logic programming">Concurrent logic</a> (<a href="Concurrent_constraint_logic_programming" title="Concurrent constraint logic programming">Concurrent constraint logic</a>)</li>

<li><a href="Concurrent_object-oriented_programming" title="Concurrent object-oriented programming">Concurrent OO</a></li>

<li><a href="Macroprogramming" title="Macroprogramming">Macroprogramming</a></li>

<li><a href="Multitier_programming" title="Multitier programming">Multitier programming</a></li>

<li><a href="Organic_computing" title="Organic computing">Organic computing</a></li>

<li><a href="Parallel_programming_model" title="Parallel programming model">Parallel programming models</a></li>

<li><a href="Partitioned_global_address_space" title="Partitioned global address space">Partitioned global address space</a></li>

<li><a href="Process-oriented_programming" title="Process-oriented programming">Process-oriented</a></li>

<li><a href="Relativistic_programming" title="Relativistic programming">Relativistic programming</a></li>

<li><a href="Service-oriented_programming" title="Service-oriented programming">Service-oriented</a></li>

<li><a href="Structured_concurrency" title="Structured concurrency">Structured concurrency</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Metaprogramming" title="Metaprogramming">Metaprogramming</a></th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Attribute-oriented_programming" title="Attribute-oriented programming">Attribute-oriented</a></li>

<li><a href="Automatic_programming" title="Automatic programming">Automatic</a> (<a href="Inductive_programming" title="Inductive programming">Inductive</a>)</li>

<li><a href="Dynamic_programming_language" title="Dynamic programming language">Dynamic</a></li>

<li><a href="Extensible_programming" title="Extensible programming">Extensible</a></li>

<li><a href="Generic_programming" title="Generic programming">Generic</a></li>

<li><a href="Homoiconicity" title="Homoiconicity">Homoiconicity</a></li>

<li><a href="Interactive_programming" title="Interactive programming">Interactive</a></li>

<li><a href="Macro_(computer_science)" title="Macro (computer science)">Macro</a> (<a href="Hygienic_macro" title="Hygienic macro">Hygienic</a>)</li>

<li><a href="Metalinguistic_abstraction" title="Metalinguistic abstraction">Metalinguistic abstraction</a></li>

<li><a href="Multi-stage_programming" title="Multi-stage programming">Multi-stage</a></li>

<li><a href="Program_synthesis" title="Program synthesis">Program synthesis</a> (<a href="Bayesian_program_synthesis" title="Bayesian program synthesis">Bayesian</a>, <a href="Inferential_programming" title="Inferential programming">Inferential</a>, <a href="Programming_by_demonstration" title="Programming by demonstration">by demonstration</a>, <a href="Programming_by_example" title="Programming by example">by example</a>)</li>

<li><a href="Reflective_programming" title="Reflective programming">Reflective</a></li>

<li><a href="Self-modifying_code" title="Self-modifying code">Self-modifying code</a></li>

<li><a href="Symbolic_programming" title="Symbolic programming">Symbolic</a></li>

<li><a href="Template_metaprogramming" title="Template metaprogramming">Template</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Separation_of_concerns" title="Separation of concerns">Separation<br>of concerns</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Aspect-oriented_programming" title="Aspect-oriented programming">Aspects</a></li>

<li><a href="Component-based_software_engineering" title="Component-based software engineering">Components</a></li>

<li><a href="Data-driven_programming" title="Data-driven programming">Data-driven</a></li>

<li><a href="Data-oriented_design" title="Data-oriented design">Data-oriented</a></li>

<li><a href="Event-driven_programming" title="Event-driven programming">Event-driven</a></li>

<li><a href="Feature-oriented_programming" title="Feature-oriented programming">Features</a></li>

<li><a href="Literate_programming" title="Literate programming">Literate</a></li>

<li><a href="Role-oriented_programming" title="Role-oriented programming">Roles</a></li>

<li><a href="Subject-oriented_programming" title="Subject-oriented programming">Subjects</a></li></ul>

</div></td></tr></tbody></table></div></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-05-30" href="https://en.wikipedia.org/wiki/?title=Reactive_programming&oldid=1293085017">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>